In the prior art, the authentication of a user with an application service is done by means of a single authentication factor, typically consisting of password (or a PIN code) allocated by the application service to the user after he is registered with the service. At this stage, the user can therefore authenticate himself with the application service by providing his user identifier and his password code.
Therefore communication of the password to the application service is supposed to demonstrate that this is indeed the legitimate user.
However, it is known that this remains weak authentication for several reasons:                the password is necessarily sufficiently short for the user to be able to memorise it,        if in addition the user is free to chose the password himself, it is known that he often makes a simplistic choice, that is to say one that is relatively easy to guess, finally, such an authentication method is vulnerable to attacks by means of spyware (spy software installed unknown to the user on his workstation and which captures the password at source when the user enters it) or to attacks of the phishing type, where the user believes that he is communicating his password to the legitimate application service whereas he has in reality been put in contact with a hostile or compromised service,        finally, if the password were to be compromised in one way or another, it is not obvious that the user will perceive this in time to prevent fraud or even repeated frauds.        
Hence the well known idea of using in addition to a first authentication factor, the password, a second authentication factor supposed to demonstrate that a hardware device in the possession of the user is actually participating in each authentication or signature transaction. In this context, the password is often a decimal number, typically from 4 to 8 digits, and it is then called a PIN.
The user is thus capable of guarding against any risk of usurpation of his identity by perceiving that he is no longer in possession of the hardware device in question. He will then be able to block his identifier.
It can be seen that the choice of the type of hardware device is not indifferent with regard to the level of security achieved: ideally, the device must be used frequently and the user must part with it as infrequently as possible.
With the level of mobile telephony equipment reached at the present time, one aspect of the invention makes provision for making the mobile telephone of the user this device constituting the second authentication factor.
However, this does not suffice: it is also necessary to move from a static authentication where it is the same authentication data that serves on each occasion to dynamic authentication where the authentication data can be used only once.
The question here is knowing how to generate such a dynamic authenticator and how this demonstrates the actual involvement of the mobile telephone of the user.
The prior art shows that it is necessary to provide a secret particular to each mobile telephone and an application for managing the dynamic authentications, after the PIN is entered, by using the secret and a diversification data item, typically a clock, a counter or a challenge coming from the application service.
This does however raise several questions that do not yet appear to have found a global response:                what should be done to be in a position to resist improper disputes of users (non-repudiation)?        how can the users reasonably have confidence in the application mentioned and how is it installed on the mobile telephones of the users?        where does the secret mentioned come from and how is it protected?        
Moreover, it is interesting to see to what extent it is possible to build a signature solution from a simple authentication solution. In fact, the problem of the signature is broken down into two parts:                is one certain that the signature emanates from the supposed user?        how to give expression to the agreement of the user in linking it to the terms of the signed transaction?        
The first part comes down to the authentication of the user by the application service that will have to deal with the transaction.
The prior art shows that, in order to deal with the second part, it is necessary to present the terms of the transaction to the user and to obtain a response on his part, the agreement or the signature, which will have to depend on these terms and on the process of his authentication. This functional requirement is referred to in English as “what you sign is what you see”. In other words, it could be said a signature is a contextual authenticator.